The Internet protocol (IP) network is becoming more and more the universal medium for a multitude of services and applications. It is the federating network adopted by operators for mutualizing their heterogeneous offers of services.
Telephony over IP advantageously makes it possible firstly to reduce the cost of telephone calls compared with conventional telephony, and secondly to couple the telephone with the functions and computer services of IP networks.
Telephony over IP also enables functions to be implemented that are already present on the public switched telephone network (PSTN). By way of example, such a function is a call transfer service enabling a called party who has been called by a calling party to transfer the call to a third party.
The transfer is said to be “consultative” if the called party engages in communication with the third party before transferring the call from the calling party.
The transfer is said to be “blind” if the transfer is implemented without consultation. A “blind” transfer achieves a saving in time and is often used by telephone switchboards, such as a business switchboard or in a call center.
In networks, e.g. voice networks, that make use of the session initiation protocol (SIP) for signaling as standardized by the Internet engineering task force (IETF), the “blind” transfer service is implemented by performing a method known as “REFER”.
In known manner, the SIP protocol makes it possible to initiate, to modify, or to terminate multimedia sessions. Once negotiation has been achieved between a calling party and a called party, the two parties may exchange media streams, e.g. voice or video, by activating a data transfer protocol, e.g. the real time transport protocol (RTP). The SIP protocol manages only the signaling messages and not the data messages of a multimedia session. The parameters of multimedia sessions are pre-negotiated via the SIP signaling messages. These parameters are mainly the termination addresses and the port numbers that are to be used by the two ends for setting up the call.
FIG. 1 shows the various steps implemented by the REFER method in the prior art.
During a step S2, the terminal of a calling party B sends an SIP “INVITE” message to a terminal of a first called party A. An SIP session is then set up between the calling party B and the first called party A. After the SIP session has been set up, a voice call is engaged between the calling party B and the first called party A.
Thereafter, e.g. at the request of the calling party B seeking to be transferred to a third party C, the first called party A sends an SIP REFER message to the calling party B (step S4). The REFER message contains an identifier of the first called party A, e.g. a uniform resource identifier (URI) address, an identifier of the third party C, e.g. a URI address, and a parameter “Replaces”. The parameter “Replaces” tells the terminal of the calling party B that it has to replace the call set up between the calling party B and the first called party A by a call between the calling party B and the third party C.
On receiving the REFER message, the calling party B sends an acknowledgment message to the called party A in order to indicate that it accepts the request to make a transfer. Thereafter, the call between the calling party B and the first called party A is disconnected. The calling party B then sends an “INVITE” message to the third party C (step S6). An SIP session is set up between the calling party B and the third party C. Thereafter a voice call is engaged between the calling party B and the third party C.
When the call cannot be set up between the calling party B and the third party C, e.g. if the third party C cannot be reached, the SIP session between the calling party B and the third party C terminates.
At present, the implementations defined in the standards do not enable the call that was initially set up between the calling party B and the first called party A to be resumed in the event of the transfer failing or prior to the transfer being set up. In other words, the session initially set up between the called party A and the calling party B cannot be reactivated.
Thus, in the event of a failure, the calling user B needs to make a new call to the terminal of the first called party A, e.g. in order to ask to be transferred to some other party.
This situation is difficult for a caller to accept, particularly since this call resumption function is implemented in the conventional PSTN network.
In addition to a waste of time, the caller has the impression that the service is not as good as it used to be.